\section{Security Applications}

SALADS can be applied to a number of security scenarios such as rootkits
defense, memory exploits (e.g.,heap overflow, double free)
mitigation, and hypervisor protection. %In this section, we demonstrate how we
%use SALADS in these scenarios.



\subsection{Rootkit Defense}


We selected 12 widely used rootkits to test the capability of the
randomized Linux kernel in defeating the rootkit attacks, and these
rootkits often deal with three data structures:
\texttt{task\_struct}, \texttt{proc\_dir\_entry} and
\texttt{module}. The kernel compiled by SALADS can successfully
defend them. Details can be found in Table~\ref{tab:rootkitdefense}.
Note that we made slight modification to some of these rootkits, for
example, \texttt{kbdy} rootkit needs to modify the system call
table, which has been marked as ``read-only" since Linux
kernel-2.6.15. \texttt{Adore-ng} rootkit modifies the fields in the
global variable \texttt{proc\_root}, which has been moved to the
``read-only" page by Linux kernel-2.6.23.1. To enable the rootkit
modify the ``read-only" pages, we modify these rootkits by setting
the \texttt{cr0} before modification, after which we recover
\texttt{cr0} again.


\begin{table*}
\begin{scriptsize}
\centering
\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|c|}\hline

Num& Rootkit Name & Data Structure & Description & Prevented?
\\\hline

1 & hideprocess-2.6 & task\_struct & hide one process with given PID
& $\checkmark$
\\\hline

2 & kbdy-2.6 & proc\_dir\_entry & give the privilege to the user
when it open proc file & $\checkmark$\\\hline

3 & adore-ng-0.56 &  task\_struct, proc\_dir\_entry, module & hide
one process when open proc file & $\checkmark$\\\hline

4 & taskigt & task\_struct,proc\_dir\_entry & give the privilege to
certain process when open proc file & $\checkmark$\\\hline

5 & enyelkm-1.3 & proc\_dir\_entry, module & hide module by
modifying the proc read system call & $\checkmark$\\\hline

6 & int3hook & module &hide process when hijacking int 3 &
$\checkmark$\\\hline

7 & synapsys & task\_struct,module& give the root privilege to
certain proess & $\checkmark$\\\hline

8 & cleaner-2.6& module & hide the next module of the rootkit &
$\checkmark$\\\hline

9 & linuxfu-2.6 & task\_struct& hide the process given its name &
$\checkmark$\\\hline

10 &modhide  & module & hide the module given its name &
$\checkmark$\\\hline

11 & override & task\_struct & hide one process using injected code
& $\checkmark$\\\hline

12 & rmroots & task\_struct, module & destroy static data structures
to hide & $\checkmark$\\\hline
\end{tabular}
\caption{Rootkits experiment under
Kernel-2.6.23.1}\label{tab:rootkitdefense} \end{scriptsize}
\end{table*}



We first compiled the Linux kernel-2.6.23.1 with the normal gcc-4.5.0
and SALADS. Then we executed the rootkits on original Linux kernel
and our layout randomized Linux kernel. On the original kernel, the effect of
the rootkits has been shown in the column ``Description" in Table
\ref{tab:rootkitdefense}. On the randomized kernel, all the rootkits
attacks have failed, and leaded to two situations: one is
the rootkit has been prevented and the kernel runs without problem,
such as \texttt{hideprocess}, \texttt{synapsys},
\texttt{linuxfu-2.6} and \texttt{override}, and the other is
causing a kernel panic. This is because these rootkits try to write
to the pointer field in the data structure but failed, and when they dereference these
pointer fields later, it will read the unexpected memory.



\subsection{Memory Exploits Mitigation}

Memory exploits often target a specific data structure field. Since
SALADS can randomize the layout of the data structures, it can be
used in exploit mitigation. In this experiment, we take two real
world exploits and randomize the corresponding data structures
showing our capability. For more generality, we take a heap
management implementation ptmalloc3~\cite{ptmalloc3} and randomize
the \texttt{malloc\_chunk} data structure to show that SALADS can be
used in heap overflow and double free prevention.


The first exploit we tested is the attack that uses
\texttt{KEY\_ARG} buffer overflow~\cite{apache-openssl} in
\texttt{openssl}. To launch this attack, it has to first overwrite
the \texttt{KEY\_ARG} array and inject the shellcode. Next, it uses
the \texttt{session->ciphers} variable to calculate the address of
the shellcode. In particular, by subtracting 368 from
\texttt{session->ciphers} pointer in the \texttt{ssl\_session\_st}
structure, the attacker will get the address of the
\texttt{ssl\_session\_st}, which is the address of the data the
attacker has overwritten. If we randomize the data structure
\texttt{session}, it will prevent the attacker using
\texttt{session->ciphers} to get the base address of the data
structure. The second exploit targets an \texttt{openssh}
vulerability~\cite{openssh}. It can be exploited to overflow the
\texttt{pw\_passwd} in the data structure \texttt{passwd}, and
circumvent the password authentication. Data structure
\texttt{passwd} is defined in \texttt{pwd.h} (GNU LIBC). If we
randomize the data structure \texttt{passwd}, it will make the
attacker harder to overflow the \texttt{pw\_passwd}.


Heap overflow and double free attacks often modify the heap
meta-data to execute arbitrary code. However, the attacker arranges
the injection code based on the definition of heap meta-data
structure. More specifically, the attackers often modify the
\texttt{fd} and \texttt{bk} in data structure
\texttt{malloc\_chunk}. Note \texttt{fd} and \texttt{bk} maintain
the double link for the unused heap memory chunks. When the program
is linked to a layout randomized \texttt{malloc\_chunk} which is
compiled by SALADS, the addresses of \texttt{fd} and \texttt{bk} are
randomized. Moreover, at runtime, the addresses of \texttt{fd} and
\texttt{bk} are dynamically changed. It will be harder for the
attacker to change
 \texttt{fd} and \texttt{bk}. To test the effectiveness of our tool, we
 randomize the data struct
\texttt{malloc\_chunk} in \texttt{glibc-2.7} and \texttt{ptmalloc3}, and
evaluate whether the programs linked to the randomized glibc-2.7 (as
a dynamic library) or randomized ptmalloc (as a static library) can
defeat the heap overflow or double free attacks.

Table~\ref{tab:memoryexploit} summarizes the effectiveness of the data
structure randomization for defeating the memory exploits. As we could see
all the tested programs compiled from SALADS can prevent the
corresponding memory exploits.

%  As we
%illustrated above, for testing the effectiveness of SALADS in
%defeating the inner fields modification, we select two applications:
%openssh and openssl (1st and 2nd row in Table~\ref{tab:memoryexploit}).
%For testing the effectiveness of heap metadata randomization, we
%selected eight attacks (3rd-10th rows). The vulnerability attack
%\cite{apache-openssl} in openssl is tested twice (row 2 and 3 in
%Table~\ref{tab:memoryexploit}): one for preventing locating the
%shellcode by \texttt{ciphers} in \texttt{ssl\_session\_st}(column
%2), the other for testing the heap overflow exploit using
%\texttt{malloc\_chunk} (column 3). Experimental results show all
%these attacks can be prevented by \texttt{malloc\_chunk}
%randomization based on SALADS.






\begin{table*}
\begin{scriptsize}
\centering
\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|c|}\hline

Num& Program Name & Vulnerability & Data Struct Name & Prevented?
\\\hline
1 & openssh-2.1.1 & CRC-32 bug\cite{openssh} & passwd &$\checkmark$
\\\hline

2 & openssl-0.9.6d & KEY\_ARG heap overflow \cite{apache-openssl} &
ssl\_session\_st & $\checkmark$ \\\hline

3 & openssl-0.9.6d & KEY\_ARG heap overflow \cite{apache-openssl} &
malloc\_chunk & $\checkmark$ \\\hline

4 & tinyproxy-1.3.2  &  Sprintf() heap overflow \cite{tiny} &
malloc\_chunk &$\checkmark$ \\\hline

5 & traceroute-1.4a5 & Double Free\cite{traceroute} & malloc \_chunk
&$\checkmark$
\\\hline

6 & nullhttpd-0.5 & Heap overflow \cite{nullhttpd} & malloc\_chunk &
$\checkmark$
\\\hline

7 & wu-ftpd 2.6.1 & Heap overflow \cite{wuftpd} & malloc\_chunk &
$\checkmark$
\\\hline

8 & WsMp3-0.0.9 & Heap Overflow \cite{wsmp3} & malloc\_chunk &
$\checkmark$\\\hline

9 &sudo-1.6.1 & Heap Overflow \cite{sudo} & malloc\_chunk &
$\checkmark$\\\hline

10 & WvTftp-0.9 & Heap Overflow \cite{WvTftp} & malloc\_chunk &
$\checkmark$\\\hline

\end{tabular}
\caption{Memory Exploit Mitigation With Data Structure
Randomization}\label{tab:memoryexploit}
\end{scriptsize}
\end{table*}

\begin{table*}
\begin{scriptsize}
\centering
\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|c|}\hline

Num& VMM & Attack & Data Struct Name & Prevented?
\\\hline
1 & Xen-3.2.0\& linux-2.6.18.8 & Blue Pill & vcpu &$\checkmark$
\\\hline

2 & Kvm-kmod-2.6.30\&qemu-kvm-0.12.2& kvm\_x86\_ops hooking&
kvm\_x86\_ops & $\checkmark$ \\\hline

3 & Kvm-kmod-2.6.30\&qemu-kvm-0.12.2& Virtunoid\cite{Virtunoid} &
RTCState & $\checkmark$
\\\hline

\end{tabular}
\caption{VMM-based Attacks Prevention} \label{tab:bluepill}
\end{scriptsize}
\end{table*}



\subsection{Hypervisor Protection} As hypervisor is a trusted platform
in the virtual machine environment by default, many attacks target
hypervisor to obtain a higher privilege of the guest OS, or even
intrude the host OS without being recognized, such as SMM
poisoning~\cite{SMM1,SMM2} and Blue Pill
attacks~\cite{Bluepill,Bluepilltech}.

In this experiment, we use Xen-3.2.0~\cite{Xen} and launch a Blue
Pill~\cite{Bluepilltech} attack to test the effectiveness of SALADS.
Since current \texttt{vcpu} structure (the Blue Pill relies on)
resides at the bottom of ring0 stack and contains many important
information (e.g., debug register of guest OS), an attacker can read
this data structure. For example, the ``Dr backdoor hooks" component
in Blue Pill uses DR3 for this purposes when Xen
scheduler selects domain0 to run. %, and meanwhile keep the stealthy
%of Blue Pill (conflict usage of DR3), it reads \texttt{debugreg}
%from current vcpu structure to check whether the guest uses DR3.
If we randomize the inner structure of \texttt{vcpu}, Blue Pill cannot extract
the information from the \texttt{vcpu}, and therefore prevents this attack.
%Note that SALADS cannot prevent the DMA method of Blue Pill to hack
%the hypercall, but it can prevent the important component ``Dr
%backdoor hooks" in Blue Pill.

Other than the Blue Pill attack, we also use one KVM rootkit and one
KVM bug exploit named Virtunoid\cite{Virtunoid} in demonstrating the
capability of SALADS. In particular, we take
Kvm-kmod-2.6.30~\cite{KVM}, and we construct a
\texttt{kvm\_x86\_ops} rootkit to modify the data structure instance
of \texttt{kvm\_x86\_ops}, which is declared as the global variable
in KVM. The data structure \texttt{kvm\_x86\_ops} contains many
fields that are function pointers, and a rootkit modifies the field
of the data structure instance of \texttt{kvm\_x86\_ops}, when KVM
uses the maliciously crafted function pointer, it will introduce the
malicious behavior. If \texttt{kvm\_x86\_ops} has been randomized by
SALADS, the attacker will modify a wrong function pointer, and hence
preventing this attack. Another attack is exploit the bug in
qemu-kvm, which does not properly check for hot plug eligibility
during device removals. But the attack relies on the memory layout
of the data structure \texttt{RTCState} to set the member variable
\texttt{QEMUTimer * second\_timer}. If \texttt{RTCState} is
randomized, the attacker can not use this flaw to crash or execute
arbitrary code. Table~\ref{tab:bluepill} summarizes our Xen and KVM
experiments in preventing Blue Pill, Virtunoid exploit and the
\texttt{kvm\_x86\_ops} rootkits.
